1. Field of the Invention
The invention relates generally to an apparatus that stores data update histories, and more specifically to a storage apparatus that includes a virtual machine monitor for storing data update histories based on a command from a file system.
2. Description of Related Art
Methods used for data update history storage apparatuses that store data update histories based on commands from existing file systems have been conventionally known, and one of these methods is disclosed in reference 1 (non-patent document: Andy Hisgen, et. al., “New-Value Logging in the Echo Replicated File System”, Research Report 104, Systems Research Center, Digital Equipment Corporation).
FIG. 13 shows the outline of a method for a data update history storage apparatus 1300 disclosed in reference 1. In this conventional method, when a file handling unit 111″ (including a file creation unit, a file deletion unit and a file edit unit) included in a file system 102″ updates buffer data stored in a page area in a main memory, data update processing is started. Here, the “page area” means an area divided from the storage area of a buffer pool 121″. The “buffer data” indicates data that is temporarily stored in the buffer pool 121″ and will eventually be stored in data storage.
When the file handling unit 111″ in the file system 102″ declares the update of a page or commit of a transaction, a function call is issued to a page update register unit 211 or a transaction controller 212 included in a journaling library 201, and data update in a storage unit 105″ is started.
The journaling library 201 includes the page update register unit 211, the transaction controller 212 and a log area writer 115″.
When receiving update declaration regarding buffer data in the buffer pool 121″ from the file handling unit 111″, the page update register unit 211 registers in an update queue 125″ the data area 126″ block number (shown as “blkno” in FIG. 13) to be updated and update data (shown as “data” in FIG. 13) resulting from the update of the relevant buffer data in the buffer pool 121″.
Also, when receiving the commit declaration of the update transaction, which has been performed by the file system 102″ for the buffer data in the buffer pool 121″, the transaction controller 212 registers a commit entry (shown as “commit” in FIG. 13) that defines the end of the transaction in the update queue 125″.
The log area writer 115″ stores a series of update histories 125″A . . . 125″N, which have been stored in the update queue 125, in a log area 127″ in the storage unit 105″. The storage unit 105″ copies the update data contained in the update history 125″A stored in the log area 127 to the corresponding block number in the data area 126″ and updates data in this data area 126″.
By performing the above data update processing, data update performed by the file system 102″ is constantly reflected in chronological order in the data area 126″ in the storage unit 105″. Even if the file system 102″ or the journaling library 201 crashes during the copy of update data stored in the log area 127″ to the data area 126″, the data in the data area 126″ can be easily recovered because the update history 125A″ remains in the log area 127″.
However, in order to store the update history in the log area in the storage apparatus, the file handling unit in the existing file system has to issue a function call for the page update declaration or the transaction commit declaration. Accordingly, the source code of the existing file system has to be modified, which requires a large development cost.